Add friendly_id gem and update node paths on changing title #600

ananyo2012 · 2016-07-01T14:19:16Z

Make sure these boxes are checked before your pull request is ready to be reviewed and merged. Thanks!

tests pass -- rake test
code is in uniquely-named feature branch, and has been rebased on top of latest master (especially if you've been asked to make additional changes)
pull request are descriptively named
if possible, multiple commits squashed if they're smaller changes
reviewed/confirmed/tested by another contributor or maintainer
schema.rb.example has been updated if any database migrations were added

Important

To make use of the changes we need to populate the new slug column for the existing data in the database. So we have to run this query from the rails console.

DrupalNode.find_each(&:save)

Thanks!

ananyo2012 · 2016-07-01T15:19:18Z

This solves the issue of updating node titles when titles are changed. Since wiki pages, notes, questions, and maps come under the same umbrella model of drupal_node with varying paths so I have continued using node paths as it is for nodes. Just adding a update_path method which will be executed before updating the node. This updates the node paths when title are changed.

ananyo2012 · 2016-07-01T15:23:06Z

Now coming to the role of friendly_id here. Once node paths are updated older path becomes obsolete. So people will land up with 404's if trying to visit the nodes will old urls. Here comes friendly_id's :history module which saves from any 404's and it is possible to redirect old url's to new ones.

ananyo2012 · 2016-07-01T16:23:49Z

app/models/drupal_node.rb

-  end
+  # def slug
+  #  self.path.split('/').last
+  # end



Need to comment this due to new slug column introduced in the node table.

How are slug and path different?

In the present context path is the full url of a node like /notes/used/07-06-2016/some-test-url while slug is only the parameterized version of title like some-test-url

Let's just delete this method, sound good?

Yeah now we can remove this.

ananyo2012 · 2016-07-01T16:31:49Z

@jywarren Please review these changes once you are back. I have added tests and also updated previous tests so that these new changes stand right. I have also left comments in the code that will make it easier to follow.

Thanks!

ananyo2012 · 2016-07-01T16:34:06Z

I haven't updated the sqlite and schema files for any of these changes. I will do it with a follow up PR once you merge in both my PR's

ananyo2012 · 2016-07-02T07:49:06Z

app/controllers/wiki_controller.rb

@@ -142,6 +138,7 @@ def update
          i.vid = @revision.vid 
          i.save
        end
+        @node.title = @revision.title


This solves #7

jywarren · 2016-07-06T12:36:07Z

db/migrate/20160630133409_add_slug_to_nodes.rb

+  end
+
+  def down
+  	remove_index :node, :slug


just two spaces, please, thanks!

@jywarren Ah overlooked it. Updated.

jywarren · 2016-07-06T12:40:56Z

Ah, so we'd originally decided that we should not ever change the slug once its saved, as that will break any previous links, and for wiki pages, it would move the wiki page itself. So I think we must ask around if this new behavior is OK (on the dev list, maybe, and also @ebarry)? Just to be clear, it would:

change slugs to match title when title is updated
keep old paths (urls) active and 301-redirect them to new path

What happens for wiki pages? What if you move a wiki page and then want to make a new wiki page where the old one was? What if you want to change it back to the original title but the redirect record exists? If you retitle it twice -- does it doubly redirect?

In general, I like the simpler find instead of find_by_slug methods, but I'm worried about the redundancy of the slug and path columns. If we do choose to go forward here (and I appreciate the effort!) I'd like to write a bit of documentation at the top of the drupal_node file to make it clear to other developers.

ananyo2012 · 2016-07-06T20:07:49Z

@jywarren I have made some changes to the code. Please review. Now the answers to your questions. Friendly_id has its own system to handle duplicate slugs. So all slugs are unique and no two slugs are the same. So if there is already a slug named some some-test-url then if there is a updated node having same title as Some test url the slug would be some-test-url--2 i.e. an index number with a separator is appended to the url.

If we change the title of wiki page and then create an wiki with the title similar to the old title of the previous wiki a new slug will be assigned which will be unique and different from the slug of the old url of the previous wiki according to the format stated above
If we want to change the title of a wiki again to its original title and no similar title exists then it will just use the original url
But if we want to change the title of the wiki to its original title but there already exists another wiki with the old title then a new unique url will be generated as per the format stated above.

So using friendly_id ensures that no wiki pages are lost and also the slug generated is unique and older urls are redirected back to the newer urls.

ananyo2012 · 2016-07-06T20:25:16Z

@jywarren I will add some more tests to cover the cases you mentioned.

ananyo2012 · 2016-07-06T20:31:27Z

Well we could use just friendly_id slugs for node paths as friendly_id itself handles paths but I didn't want to completely switch over to friendly_id as it would involve changing a lot of code and the current path column had to be discarded. So to keep the best of both worlds so that node paths update as well as old urls are not lost I used the current path column along with friendly_id. To use the friendly_id :history module we need to have a slug column.

jywarren · 2016-07-08T04:43:26Z

Ah, but just to be clear, sorry -- if you have a page like /wiki/barnraising which you then change to /wiki/barnraising-2015, and then want to make a new page called simply /wiki/barnraising again, would the old URL be available again to make this new page? Or would the old URL persist and redirect to the new /wiki/barnraising-2015?

Second, do I understand correctly then, that node.path is used as the primary path, and node.slug is used in some way for the history -- that is, preserving old URLs?

Thanks, this is a bit subtle and we need to have a clear understanding -- and to ensure people can get the URL they need on a wiki page. Note that for research notes the URL must simply be permanent for linking to (and exactly what the URL becomes is not that important-- it can have "-2" at the end with no problem), but for wikis, having a "good" or recognizable short URL is important too, and "losing" the ability to put a page at a well-known URL is more serious.

ananyo2012 · 2016-07-08T17:30:16Z

If you have a page like /wiki/barnraising which you then change to
/wiki/barnraising-2015, and then want to make a new page called simply
/wiki/barnraising again, the old url won't be used instead a unique url
like /wiki/barnraising--2.

Yes its somewhat like that. The node.path is the primary path and the slug
is used by the history module.
ᐧ

On Fri, Jul 8, 2016 at 10:13 AM, Jeffrey Warren notifications@github.com
wrote:

Ah, but just to be clear, sorry -- if you have a page like
/wiki/barnraising which you then change to /wiki/barnraising-2015, and
then want to make a new page called simply /wiki/barnraising again, would
the old URL be available again to make this new page? Or would the old URL
persist and redirect to the new /wiki/barnraising-2015?

Second, do I understand correctly then, that node.path is used as the
primary path, and node.slug is used in some way for the history -- that
is, preserving old URLs?

Thanks, this is a bit subtle and we need to have a clear understanding --
and to ensure people can get the URL they need on a wiki page. Note that
for research notes the URL must simply be permanent for linking to (and
exactly what the URL becomes is not that important-- it can have "-2" at
the end with no problem), but for wikis, having a "good" or recognizable
short URL is important too, and "losing" the ability to put a page at a
well-known URL is more serious.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AKACR308tcl8r_uBk9FuFHPsGtzsRJsdks5qTdVvgaJpZM4JDL2B
.

jywarren · 2016-07-08T17:42:48Z

Ah, hmmm. So you wouldn't be able to use /wiki/barnraising anymore? I think
we have to think of a way around that if we're going to incorporate this
code. @ebarry?
On Jul 8, 2016 10:30 AM, "Ananya Maiti" notifications@github.com wrote:

if you have a page like /wiki/barnraising which you then change to
/wiki/barnraising-2015, and then want to make a new page called simply
/wiki/barnraising again, the old url won't be used instead a unique url
like /wiki/barnraising--2.

Yes its somewhat like that. The node.path is the primary path and the slug
is used by the history module.
ᐧ

On Fri, Jul 8, 2016 at 10:13 AM, Jeffrey Warren notifications@github.com
wrote:

Ah, but just to be clear, sorry -- if you have a page like
/wiki/barnraising which you then change to /wiki/barnraising-2015, and
then want to make a new page called simply /wiki/barnraising again, would
the old URL be available again to make this new page? Or would the old
URL
persist and redirect to the new /wiki/barnraising-2015?

Second, do I understand correctly then, that node.path is used as the
primary path, and node.slug is used in some way for the history -- that
is, preserving old URLs?

Thanks, this is a bit subtle and we need to have a clear understanding --
and to ensure people can get the URL they need on a wiki page. Note that
for research notes the URL must simply be permanent for linking to (and
exactly what the URL becomes is not that important-- it can have "-2" at
the end with no problem), but for wikis, having a "good" or recognizable
short URL is important too, and "losing" the ability to put a page at a
well-known URL is more serious.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#600 (comment),
or mute
the thread
<
https://github.com/notifications/unsubscribe/AKACR308tcl8r_uBk9FuFHPsGtzsRJsdks5qTdVvgaJpZM4JDL2B

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AABfJ8-MnFGzH4hRqU1X0X3FDASccyumks5qTokpgaJpZM4JDL2B
.

ananyo2012 · 2016-07-08T17:43:51Z

I am trying to figure out how to reuse the old urls. But do we really need
it? Since in the present situation too, a new wiki page with the same url
can't be made
ᐧ

On Fri, Jul 8, 2016 at 11:00 PM, Ananyo Maiti ananyoevo@gmail.com wrote:

if you have a page like /wiki/barnraising which you then change to
/wiki/barnraising-2015, and then want to make a new page called simply
/wiki/barnraising again, the old url won't be used instead a unique url
like /wiki/barnraising--2.

Yes its somewhat like that. The node.path is the primary path and the slug
is used by the history module.
ᐧ

On Fri, Jul 8, 2016 at 10:13 AM, Jeffrey Warren notifications@github.com
wrote:

Ah, but just to be clear, sorry -- if you have a page like
/wiki/barnraising which you then change to /wiki/barnraising-2015, and
then want to make a new page called simply /wiki/barnraising again,
would the old URL be available again to make this new page? Or would the
old URL persist and redirect to the new /wiki/barnraising-2015?

Second, do I understand correctly then, that node.path is used as the
primary path, and node.slug is used in some way for the history -- that
is, preserving old URLs?

Thanks, this is a bit subtle and we need to have a clear understanding --
and to ensure people can get the URL they need on a wiki page. Note that
for research notes the URL must simply be permanent for linking to (and
exactly what the URL becomes is not that important-- it can have "-2" at
the end with no problem), but for wikis, having a "good" or recognizable
short URL is important too, and "losing" the ability to put a page at a
well-known URL is more serious.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#600 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AKACR308tcl8r_uBk9FuFHPsGtzsRJsdks5qTdVvgaJpZM4JDL2B
.

ananyo2012 · 2016-07-09T11:53:46Z

Currently friendly_id doesn't support this but I saw a PR
norman/friendly_id#663 where this was mentioned. So
there is a possible solution. Though I am not yet convinced why to reuse
the old urls as it is not so even in the present state. But it would be
great to know your views on it.
ᐧ

On Fri, Jul 8, 2016 at 11:13 PM, Ananyo Maiti ananyoevo@gmail.com wrote:

I am trying to figure out how to reuse the old urls. But do we really need
it? Since in the present situation too a new wiki page with the same url
can't be made
ᐧ

On Fri, Jul 8, 2016 at 11:00 PM, Ananyo Maiti ananyoevo@gmail.com wrote:

if you have a page like /wiki/barnraising which you then change to
/wiki/barnraising-2015, and then want to make a new page called simply
/wiki/barnraising again, the old url won't be used instead a unique url
like /wiki/barnraising--2.

Yes its somewhat like that. The node.path is the primary path and the
slug is used by the history module.
ᐧ

On Fri, Jul 8, 2016 at 10:13 AM, Jeffrey Warren <notifications@github.com

wrote:

Ah, but just to be clear, sorry -- if you have a page like
/wiki/barnraising which you then change to /wiki/barnraising-2015, and
then want to make a new page called simply /wiki/barnraising again,
would the old URL be available again to make this new page? Or would the
old URL persist and redirect to the new /wiki/barnraising-2015?

Second, do I understand correctly then, that node.path is used as the
primary path, and node.slug is used in some way for the history -- that
is, preserving old URLs?

Thanks, this is a bit subtle and we need to have a clear understanding
-- and to ensure people can get the URL they need on a wiki page. Note that
for research notes the URL must simply be permanent for linking to (and
exactly what the URL becomes is not that important-- it can have "-2" at
the end with no problem), but for wikis, having a "good" or recognizable
short URL is important too, and "losing" the ability to put a page at a
well-known URL is more serious.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#600 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AKACR308tcl8r_uBk9FuFHPsGtzsRJsdks5qTdVvgaJpZM4JDL2B
.

jywarren · 2016-07-12T18:03:14Z

Hi, @ebarry and @steviepubliclab - would like your input here on if and why it's important to be able to preserver old URLs in the (not common) case that:

a page is moved, (like for example /wiki/barnraising to /wiki/barnraising-2016)
a new page is created with the title "Barnraising" with the intended (new or resuscitated) URL /wiki/barnraising)

Ananyo's done some great work here, but as it stands, it would make step 2 above impossible -- the /wiki/barnraising URL would always be locked to the renamed/moved original page, and redirected to it.

If that's OK, then I can merge this, but it's not the current behavior, and I thought we'd like to retain more flexibility over URLs.

jywarren · 2016-07-15T14:58:11Z

I think both Liz and Stevie are off today. I'll try to get their input on Monday; thanks for your patience! We just had the Regional Barnraising event in California this past weekend, so folks are still catching up (and catching their breath!)

ananyo2012 · 2016-07-16T10:52:54Z

No problem. Waiting for the reviews. @jywarren In the mean time I will add tests for the cases you pointed out. I am quite late in my schedule. Trying to manage it.

steviepubliclab · 2016-07-18T14:06:33Z

Hello! Thanks for working on this and pinging me in.

I have a couple thoughts on the URL/Redirect idea. I like the idea that the titles/urls would match if a title is changed, also like that there would be a redirect from previous URLs to the new page, but I'm worried about a situation where someone would want to make a new wiki with an old name. If there was a way to override the redirect in creating a new page, I think it's a great move.

ananyo2012 · 2016-07-18T16:54:40Z

@steviepubliclab As I have already discussed if we want to make a new wiki with a old name an url with an unique identifier will be used such as /wiki/barnraising--2, where /wiki/barnraising is the old title. There is currently no way in friendly_id to override a old url if it is used in a new item. But there is a method mentioned in norman/friendly_id#663, but that will require making changes in the gem itself.

jywarren · 2016-07-18T17:49:31Z

Is there any way to delete a redirect record? Or is that what the norman
mod does?

On Mon, Jul 18, 2016 at 11:54 AM, Ananya Maiti notifications@github.com
wrote:

@steviepubliclab https://github.com/steviepubliclab As I have already
discussed if we want to make a new wiki with a old name a url with an
unique identifier will be used such /wiki/barnraising--2 where
/wiki/barnraising is the old title. There is currently no way in
friendly_id to override a old url if it is used in a new item. But there is
a method mentioned in norman/friendly_id#663
norman/friendly_id#663, but that will require
making changes in the gem itself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABfJ2PaHhbLYp70yJzchue75W5fROg7ks5qW6_RgaJpZM4JDL2B
.

ananyo2012 · 2016-07-22T02:13:04Z

@jywarren Following your suggestion I found a solution for it. We can reuse the old slugs for new wiki pages if we delete the old slugs on new wiki creation. This way it works as expected. Now new wiki pages can use the old urls of another wiki. I have added some tests to justify it. Please have a look.

jywarren · 2016-07-22T02:51:03Z

Oh i'm so excited! I've been eager to merge this. Just to confirm, the old
urls are redirected until a new wiki tries to use the same URL, right?

On Thu, Jul 21, 2016 at 10:13 PM, Ananya Maiti notifications@github.com
wrote:

@jywarren https://github.com/jywarren Following your suggestion I found
a solution for it. We can reuse the old slugs for new wiki pages if we
delete the old slugs on new wiki creation. This way it works as expected.
Now new wiki pages can use the old urls of another wiki. I have added some
tests to justify it. Please have a look.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABfJ6PVyxevp--IhHICgDU-Bik1II6sks5qYCcxgaJpZM4JDL2B
.

ananyo2012 · 2016-08-01T22:26:44Z

Ok I have thought of something so that we won't have to change the format of the urls. I will be making an update to this PR soon.

jywarren · 2016-08-01T22:48:37Z

Thanks, Ananyo -- I'm happy to take a close look and offer input. I
appreciate your attention to this!

On Aug 1, 2016 6:26 PM, "Ananya Maiti" notifications@github.com wrote:

Ok I have thought of something so that we won't have to change the format
of the urls. I will making an update to this PR soon.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABfJ7Nt6ifhvIZOx53a01u-q7rJVLb5ks5qbnKkgaJpZM4JDL2B
.

ananyo2012 · 2016-08-08T18:15:25Z

app/controllers/notes_controller.rb

@@ -90,8 +90,10 @@ def raw

  def show
    if params[:author] && params[:date]
-      @node = DrupalNode.where(path: "/notes/#{params[:author]}/#{params[:date]}/#{params[:id]}").first
+      finder = "#{params[:author]} #{params[:date]} #{params[:id]}".parameterize


@jywarren This keeps the url format intact. I am just creating a finder string from the parameters that finds the appropriate node using the friendly_id slug. Thus we can use best of both worlds! Not modifying the url format as well as using the friendly_id for old url redirects. while updating the url as the title changes.

ananyo2012 · 2016-08-08T18:17:22Z

@jywarren I have solved the problem discussed earlier. Also rebased on the latest master. Please review the changes.

jywarren · 2016-08-09T08:20:29Z

Wow, exciting; checking this out now.

jywarren · 2016-08-09T08:25:03Z

app/models/drupal_node.rb

+    slug.blank? || title_changed?
+  end
+
+  def pretty_url


Perhaps this should be called "friendly_id_generator" or "friendly_id_adaptor" as the string it returns is not actually used as a URL.

or friendly_id_string?

friendly_id_string sounds perfect

jywarren · 2016-08-09T08:34:15Z

This looks great. I just added a couple small requests and we're basically done. Thanks!

ananyo2012 · 2016-08-09T16:42:09Z

@jywarren I have updated the PR as you requested. Also updated the schema file.Please review.

Create migrations for slug column and friendly_id_slug table

Add update method to update node path Modify show action in controllers for finding object by slugs

Create friendly_id_slugs fixture for history module

Add integration tests for corresponding changes

…rmat intact Define down method for rename long column migration

jywarren · 2016-08-12T09:28:16Z

Running tests... this is a huge update, Ananyo!

jywarren · 2016-08-12T09:36:15Z

We're going to have to watch out extra carefully for any issues that crop up, but your tests look quite thorough.

Bundle updated, migrations run... tests running...

All good! Wow. Merging...

jywarren · 2016-08-12T09:36:38Z

Congratulations, this was a big one. Thanks for sticking with it and for all your hard work on it!

ananyo2012 · 2016-08-12T14:15:05Z

@jywarren Thanks for patience and time Jeff. You also stuck to it till the end. Once again to remind you you need to run this command in the rails console to initialize all the slug column of the nodes.

DrupalNode.find_each(&:save)

I will also look at any issues that may creep up after this and solve it asap. Thanks a lot Jeff!

jywarren · 2016-08-12T18:07:33Z

Oh, I should've mentioned, you can add that command to the migration--
could you add a follow-up migration with that command and it'll run when I
next publish to the live server? It can contain just that line.

On Aug 12, 2016 3:15 PM, "Ananya Maiti" notifications@github.com wrote:

@jywarren https://github.com/jywarren Thanks for patience and time
Jeff. You also stuck to it till the end. Once again to remind you you need
to run this command in the rails console to initialize all the slug column
of the nodes.

DrupalNode.find_each(&:save)

I will also look at any issues that may creep up after this and solve it
asap. Thanks a lot Jeff!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#600 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABfJ9xTRA-H9IQD42nvANhyIBWAFItuks5qfH_pgaJpZM4JDL2B
.

ananyo2012 reviewed Jul 1, 2016
View reviewed changes

ananyo2012 reviewed Jul 2, 2016
View reviewed changes

ananyo2012 mentioned this pull request Jul 2, 2016

search page returns original wiki page title #7

Closed

jywarren reviewed Jul 6, 2016
View reviewed changes

ananyo2012 force-pushed the friendly_id branch 2 times, most recently from 43b7584 to c625c3f Compare July 6, 2016 19:29

ananyo2012 force-pushed the friendly_id branch 2 times, most recently from 02a8bff to c968e35 Compare July 22, 2016 02:09

ananyo2012 force-pushed the friendly_id branch from 5f70304 to 0f7d6b5 Compare August 8, 2016 18:11

ananyo2012 reviewed Aug 8, 2016
View reviewed changes

jywarren reviewed Aug 9, 2016
View reviewed changes

ananyo2012 force-pushed the friendly_id branch from 0f7d6b5 to 11db795 Compare August 9, 2016 16:34

ananyo2012 added 7 commits August 10, 2016 19:57

Add friendly_id gem

44c5a33

Create migrations for slug column and friendly_id_slug table

Extend friendly_id to drupal_node model

bfd7860

Add update method to update node path Modify show action in controllers for finding object by slugs

Add integration tests for updating node title

90f1f9e

Create friendly_id_slugs fixture for history module

Delete old slug while creating new wiki with same title

ec2c21d

Add integration tests for corresponding changes

Modify friendly_id slug format according to note type and keep url fo…

09d0fe6

…rmat intact Define down method for rename long column migration

Modify fixtures and fix failing tests

99206fd

Change timestamps for migration and update schema file

2ddd336

ananyo2012 force-pushed the friendly_id branch from 11db795 to 2ddd336 Compare August 10, 2016 14:27

jywarren merged commit ae9b01e into publiclab:master Aug 12, 2016

ananyo2012 deleted the friendly_id branch August 16, 2016 07:38

ananyo2012 mentioned this pull request Aug 16, 2016

Add migration for seeding friendly_id slugs column #665

Closed

6 tasks

Add friendly_id gem and update node paths on changing title #600

Add friendly_id gem and update node paths on changing title #600

Conversation

ananyo2012 commented Jul 1, 2016 • edited Loading

Important

ananyo2012 commented Jul 1, 2016

ananyo2012 commented Jul 1, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ananyo2012 commented Jul 1, 2016

ananyo2012 commented Jul 1, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jywarren commented Jul 6, 2016

ananyo2012 commented Jul 6, 2016 • edited Loading

ananyo2012 commented Jul 6, 2016 • edited Loading

ananyo2012 commented Jul 6, 2016

jywarren commented Jul 8, 2016

ananyo2012 commented Jul 8, 2016 • edited Loading

jywarren commented Jul 8, 2016

ananyo2012 commented Jul 8, 2016 • edited Loading

ananyo2012 commented Jul 9, 2016

jywarren commented Jul 12, 2016

jywarren commented Jul 15, 2016

ananyo2012 commented Jul 16, 2016 • edited Loading

steviepubliclab commented Jul 18, 2016

ananyo2012 commented Jul 18, 2016 • edited Loading

jywarren commented Jul 18, 2016

ananyo2012 commented Jul 22, 2016

jywarren commented Jul 22, 2016

ananyo2012 commented Aug 1, 2016 • edited Loading

jywarren commented Aug 1, 2016

Choose a reason for hiding this comment

ananyo2012 commented Aug 8, 2016

jywarren commented Aug 9, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jywarren commented Aug 9, 2016

ananyo2012 commented Aug 9, 2016 • edited Loading

jywarren commented Aug 12, 2016

jywarren commented Aug 12, 2016

jywarren commented Aug 12, 2016

ananyo2012 commented Aug 12, 2016

jywarren commented Aug 12, 2016

ananyo2012 commented Jul 1, 2016 •

edited

Loading

ananyo2012 commented Jul 1, 2016 •

edited

Loading

ananyo2012 commented Jul 6, 2016 •

edited

Loading

ananyo2012 commented Jul 6, 2016 •

edited

Loading

ananyo2012 commented Jul 8, 2016 •

edited

Loading

ananyo2012 commented Jul 8, 2016 •

edited

Loading

ananyo2012 commented Jul 16, 2016 •

edited

Loading

ananyo2012 commented Jul 18, 2016 •

edited

Loading

ananyo2012 commented Aug 1, 2016 •

edited

Loading

ananyo2012 commented Aug 9, 2016 •

edited

Loading